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ABSTRACT:  One  Semi-Automated  Forces  (OneSAF)  is  the  United  States  (U.S.)  Army’ s  next  generation  simulation 
system  being  developed  to  provide  an  integral  simulation  service  to  the  Advanced  Concepts  and  Requirements 
(ACR),  Training,  Exercises,  and  Military  Operations  (TEMO),  and  Research,  Development,  and  Acquisition  (RDA) 
domains.  With  requirements  ranging  from  closed-form  analytical  support  to  command  level  human  in  the  loop 
training,  OneSAF  will  be  an  HLA  compliant  entity  level  simulation.  OneSAF  will  provide  simulation  of  individual 
battlefield  components  such  as  soldiers,  tanks,  and  helicopters  through  aggregate  units,  to  the  Brigade  level, 
operating  in  either  a  completely  automated  mode  or  under  the  control  of  the  training  audience  via  their  organic 
command  and  control  systems  or  role  players  using  a  OneSAF  Graphical  User  Interface  (GUI).  Simulation  entities, 
units,  behaviors,  and  the  synthetic  environment  will  be  composable  to  provide  the  greatest  flexibility  to  the  user  in 
rapidly  meeting  the  scenario  requirements  for  a  simulation  event.  Composition  will  allow  not  only  ordinary  task 
organizations  to  be  defined  with  doctrinally  correct  behaviors  and  ordinary  equipment  sensor  combinations,  but 
will  also  support  new  concepts  in  combining  equipment  and  sensor  pairs  as  well  as  new  equipment  and  behavior 
combinations.  These  ambitious  requirements  force  a  new  tactic  in  simulation  development.  This  paper  describes 
the  innovative  Product  Line  approach  the  U.S.  Army’ s  Simulation,  Training  and  Instrumentation  Command 
(STRICOM)  is  using  to  manage  the  OneSAF  development.  In  doing  so  it  details  the  combination  of  Military  subject 
matter  experts  and  organizations,  processes,  and  technologies  that  went  into  the  development  of  the  OneSAF 
concept  and  the  integrated  repository  that  houses  the  OneSAF  operational  and  technical  requirements,  government 
directed  reuse  requirements,  and  the  Product  Line  Architecture  Framework  (PLAF). 


1  Introduction 

The  One  Semi-Automated  Forces  (OneSAF)  Objective 
System  is  the  United  States  (U.S.)  Army’s  next 
generation,  composable,  entity  based  simulation  system. 


It  is  being  developed  to  provide  an  integral  simulation 
service  to  the  Advanced  Concepts  and  Requirements 
(ACR),  Training,  Exercises,  and  Military  Operations 
(TEMO),  and  Research,  Development,  and  Acquisition 
(RDA)  domains.  With  requirements  ranging  from 
closed-form  analytical  support  to  command  level  human 
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in  the  loop  training,  OneSAF  will  be  a  High  Level 
Architecture  (HLA)  compliant  entity  level  simulation 
providing  a  common  solution  for  a  broad  range  of  user 
requirements.  In  order  to  realize  this  vision  an 
innovative  product  line  management  and  development 
approach  has  been  selected. 

The  primary  purpose  of  this  paper  is  to  describe  the 
organizations,  the  foundational  technical  products,  and 
the  technologies  enabling  OneSAF  to  pursue  this 
product  line  solution. 

1.1  Background 

The  OneSAF  concept  originated  in  January  1996 
following  an  extensive  study  that  came  to  the 
conclusion  that  the  Army  was  caught  in  a  wasteful 
spending  cycle,  making  identical  or  similar 
enhancements  to  legacy  simulations  across  three 
different  user  domains. 

Furthermore,  it  was  determined  that  none  of  the  existing 
legacy  simulations  were  capable  of  being  extended  to 
provide  comprehensive  support  of  emerging  Army 
functional  requirements  and  technical  standards. 

Realizing  this,  the  Army  decided  the  best  approach  for 
overcoming  the  problems  associated  with  the  multitude 
of  aging  simulations  was  to  create  a  single  general- 
purpose  entity  level  simulation.  This  solution  relies  on 
using  lessons  learned  from  successful  simulation 
projects  like  the  Modular  Semi-Automated  Forces 
(ModSAF)  simulation,  and  the  Close  Combat  Tactical 
Trainer  (CCTT)  SAF.  [6] 

In  May  of  1997  the  Deputy  Commanding  General 
(DCG),  Training  and  Doctrine  Command  (TRADOC) 
approved  the  Mission  Needs  Statement  (MNS)  for 
OneSAF  which  stated  [7]: 

“The  need  for  OneSAF  capabilities  is  not  a  response  to 
a  specific  warfighting  threat  against  the  force;  the  need 
is  driven  by  the  guidance  to  reduce  duplieation  of  M&S 
investments,  foster  interoperability  and  reuse  across 
M&S  domains,  and  meet  the  M&S  requirements  of  the 
future  force.  ” 

Shortly  thereafter,  a  Cross-Domain  Integrated  Concept 
Team  was  established  to  design  a  simulation  acquisition 
strategy,  draft  a  program  management  plan,  and  begin 
harmonizing  user  requirements.  This  effort  has  evolved 
over  the  past  4  years  and  is  now  culminating  in 
contracts  being  awarded  for  development  of  the 
OneSAF  Product  Line  Architecture  and  the  various 
composable  products  and  components. 


2  Army  Community  Involvement 

The  Army  had  a  monumental  task  in  coordinating  the 
various  user  domains,  the  combat  developer,  and  the 
acquisition  community  in  order  to  create  a  single 
operational  and  technical  vision  for  OneSAF.  This 
section  describes  the  various  Army  organizations  that 
have  been  involved  in  OneSAF  program  since  its 
inception.  We  begin  with  an  introduction  to  the  three 
user  domains  in  order  to  provide  the  necessary  insight 
into  their  roles  within  the  OneSAF  program.  This  is 
followed  by  a  description  of  TRADOC  and  STRICOM 
and  their  role  in  the  OneSAF  acquisition.  Finally,  the 
organizational  constructs  that  have  evolved  during  the 
OneSAF  concept  formulation  and  initial  contracting 
phases  are  explained. 

2.1  Advanced  Concept  Requirements  Domain 
(ACR) 

The  ACR  domain  is  under  the  direction  of  the 
TRADOC  Analysis  Center  (TRAC).  This  community  is 
primarily  interested  in  the  analytical  application  of 
modeling  and  simulation.  Their  intended  uses  of 
OneSAF  include  the  following: 

•  To  explore  new  and  advanced  concepts  with  respect 
to  equipment,  organizations,  doctrine,  and 
operational  environments, 

•  To  develop  and  evaluate  tactics  and  Operational 
Plans  for  organizations  at  Brigade  and  below, 

•  To  create  data  that  can  be  used  as  input  to  other 
closed  form  analytic  simulations,  and 

•  To  provide  training  associated  with  a  specific 
location  prior  to  real-world  deployments.  [7] 

2.2  Training  Exercise  and  Military  Operations 
Domain  (TEMO) 

This  domain  is  led  by  TRADOC ’s  National  Simulation 
Center  (NSC)  located  in  Ft.  Leavenworth,  KS.  Their 
focus  for  OneSAF  includes 

•  Unit  training  -  OneSAF  will  be  used  as  a 
simulation  driver  for  round  out  forces, 

•  Unit  commander  and  staff  training  at  battalion  and 
below  in  a  training  exercise,  workshop,  or  seminar 
environment, 

•  Unit  Division  commander  refresher  training,  and 

•  As  a  mechanism  to  link  live,  virtual,  and 
constructive  Synthetic  Theater  Of  War  like 
environments.  [7] 


2.3  Research  Development  and  Acquisition 
Domain  (RDA) 

The  U.S.  Army  Materiel  Systems  Analysis  Activity 
(AMS  A  A)  leads  the  RDA  domain  with  the  primary 
purpose  of  Simulation  Based  Acquisition  (SBA).  They 
operate  out  of  the  Aberdeen  Proving  Grounds  in 
Maryland  and  expect  to  use  OneSAF  in  support  of 

•  Weapon  systems  development  and  product 
improvement  using  appropriate  military  settings 
and  context, 

•  Technical  development,  test,  and  evaluation  support 
for  Army  modernization  objectives,  and 

•  Communications  design  and  laydown  experiments. 
[7] 


2.4  TRADOC  Program  Office,  OneSAF  (TPO 
OneSAF) 

TPO  OneSAF  is  the  Combat  Developer  for  OneSAF 
and  is  responsible  for  development  of  the  OneSAF 
Operational  Requirements  Document  (ORD)  [7].  The 
TPO  OneSAF  has  made  significant  contributions  in 
defining  specific  cross-domain  requirements  with 
support  from  the  RDA,  ACR,  and  TEMO  user 
communities. 

2.5  Simulation,  Training  and  Instrumentation 
Command  (STRICOM) 

STRICOM  serves  as  the  Materiel  Developer  for 
OneSAF.  The  Commander  of  STRICOM  was  delegated 
as  the  Milestone  Decision  Authority  (MDA)  for 
OneSAF  by  the  Army  Material  Command  in  May  of 
2000  concurrent  with  the  official  standup  within 
STRICOM  of  the  Product  Manager  OneSAF  (PM 
OneSAF)  office.  STRICOM/PM  OneSAF  has  been  and 
continues  to  be  the  focal  point  for  all  OneSAF  concept 
exploration  efforts  and  development  contracts.  As 
OneSAF  transitions  out  of  concept  exploration 
STRICOM  will  use  its  existing  STRICOM  Omnibus 
Contract  (STOC)  as  the  vehicle  to  access  the  simulation 
and  software  development  expertise  to  create  OneSAF. 
PM  OneSAF  also  provides  the  coordination  function  to 
ensure  the  User  Domains  remain  involved  in  the 
contracting  and  simulation  development  process. 

2.6  OneSAF  Overarching  Integrated  Product 
Team  (OIPT) 

The  fundamental  purpose  of  the  OIPT  is  to  ensure  the 
OneSAF  program  understands  and  is  responsive  to  the 
strategic  guidance  of  the  MDA.  In  a  nutshell,  the  MDA 


decides  whether  the  OneSAF  program  is  meeting  its 
cost,  schedule,  and  performance  requirements  and 
should  continue  to  receive  funding.  The  OIPT  also  has 
a  range  of  senior  management  responsibilities  from 
coordinating  the  various  OneSAF  activities  to  acting  as 
an  independent  watchdog  for  cost,  schedule  and 
performance  and  providing  these  insights  back  to  the 
MDA.  The  group  is  led  by  an  MDA  designee  and  is 
made  up  of  representatives  from  the  OneSAF  Program 
Office,  the  TRADOC  Project  Office  (TPO),  the  Army 
Model  and  Simulation  Office  (AMSO),  the  ACR 
domain,  the  RDA  domain,  and  the  TEMO  domain.  [8] 

In  order  to  meet  its  objectives,  the  OIPT  created  three 
subordinate  IPTs:  the  requirements  IPT,  the  OneSAF 
Testbed  Baseline  (0TB)  IPT,  and  the  Architecture  IPT. 

The  Requirements  IPT  was  focused  on  capturing 
OneSAF  requirements  across  all  domains  and  assessing 
them  for  commonality  and  variability.  This  group 
maintains  the  MNS  and  the  Operational  Requirements 
Document  (ORD)  in  addition  to  recommending  specific 
requirement  prioritization  to  the  OIPT. 

The  0TB  IPT  controls  the  0TB  development  process. 
This  includes  tracking  and  scheduling  of  user 
requirements,  verifying  the  user  feedback  process  is 
executing  smoothly,  and  ensuring  new  and  relevant 
technologies  are  integrated  into  the  0TB. 

These  two  IPTs  are  important  in  their  own  right. 
However,  the  remainder  of  this  paper  concentrates  on 
the  products  of  the  Architecture  IPT  as  this  group  has 
provided  the  technical  underpinnings  of  the  OneSAF 
development  process. 

2.7  OneSAF  Architecture  Integrated  Product 
Team  (A-IPT) 

The  OneSAF  A-IPT  was  chartered,  in  support  of  the 
OIPT,  in  April  of  1999  under  the  leadership  of  the 
OneSAF  Chief  Engineer  [9].  Primary  membership 
includes  representatives  from  the  OneSAF  TPO,  the 
ACR,  RDA,  and  TEMO  domains,  as  well  as  support 
from  the  MITRE  Corporation.  At  inception,  the  team’s 
primary  responsibility  was  to  develop  a  Product  Line 
Architecture  Framework  to  support  and  bound  the 
OneSAF  procurement  process.  In  doing  so  the  group 
performed  various  experiments  and  concept 
explorations  to  assess  and  understand  the  OneSAF 
architectural  driving  requirements  such  as  scalability, 
distributed  simulation,  and  optimistic  and  conservative 
time  management  schemes.  The  group  actively 
developed  products  during  the  period  of  April  1999 
through  December  of  2000. 


The  products  and  technology  involved  will  be  discussed 
in  later  sections  but  the  primary  contributions  of  the 
Architecture  team  include  the  Product  Line  Architecture 
Framework  (PLAF),  the  Technical  Requirements 
Document  (TRD),  the  Operational  Concept  Document 
(OCD),  and  the  Reuse  Direction  and  Guidance  (RDG) 
Document.  All  of  these  products  are  housed  and 
controlled  in  what  is  termed  the  OneSAF  Electronic 
Information  Environment. 

2.8  Web  Based  OneSAF  Electronic  Information 
Environment 

All  of  the  relevant  government  OneSAF  information  is 
available  electronically  through  the  OneSAF  Web  Site 
(www.onesaf  org).  This  website  was  initiated  to  serve 
as  the  repository  for  both  the  OneSAF  Objective  System 
and  the  0TB.  Both  public  and  private  (user 
account/password)  access  are  supported.  It  is  intended 
to  be  the  one  stop-shopping  site  for  OneSAF  relevant 
data.  The  private  website,  in  addition  to  offering  web 
based  search  and  information  access  also  provides 
interactive  chat  collaboration  tools  and  A-IPT  meeting 
notes  and  briefings.  At  the  heart  of  the  private  section  is 
the  OneSAF  Electronic  Information  Environment  built 
upon  the  commercially  available  Dynamic  Object 
Oriented  Requirements  System  (DOORS).  [16]  The 
logical  layout  of  the  DOORS  repository  is  shown  in 
figure  2.1.  It  holds  all  of  the  current  government 
generated  products  and  will  eventually  hold  the 
contractor  developed  specifications  and  designs.  In 
addition  DOORS  is  used  to  hold  the  traceability 
mappings  from  architecture  and  design  specifications 
and  other  development  artifacts  back  to  the  operational 
requirements. 


Figure  2.1,  Electronic  Information  Environment  Logical 
Layout 


3  The  OneSAF  Technical  Foundation 

The  A-IPT  created  a  number  of  technical  products 
between  April  1999  and  December  2000  with  the  goal 
of  articulating  the  government’s  product  line  concepts 
and  requirements  to  the  modeling  and  simulation 
development  community  and  other  external 
organizations.  These  products  supplement  the  OneSAF 
ORD  and  are  intended  to  be  used  as  direction  and 
guidance  in  the  development  of  the  OneSAF  Product 
Line.  As  mentioned  earlier,  the  A-IPT  products  include 
the  PLAF,  TRD,  OCD,  and  the  RDG  Document. 

The  intent  of  the  government  direction  is  to  reduce  cost 
and  development  timelines  and  increase  overall  system 
performance.  Although  other  implementations  can  be 
generated  it  is  incumbent  on  the  contracting 
organization  to  present  compelling  evidence  of 
substantial  lifecycle  savings  in  order  to  change  the 
direction. 

The  PLAF  is  intended  to  identify  basic  products, 
components,  and  interfaces  that  support  the  entirety  of 
the  OneSAF  requirements.  It  also  relates  a  set  of 
guiding  principles  for  the  product  line  based 
architecture.  It  is  envisioned  that  the  OneSAF 
Architecture  and  Integration  contractor  will  revise  and 
extend  the  PLAF  to  become  the  formal  OneSAF 
Product  Line  Architecture  Specification  (PLAS)  that 
fully  specifies  the  architectural  products,  components, 
interfaces,  and  services. 

Finally,  the  TRD  and  OCD  are  considered  transitional 
products  intended  to  provide  tools  for  the  Architecture 
and  Integration  contractor  to  construct  the  OneSAF 
Product  Line  Requirements  Specification  (PLRS)  and 
the  final  Operational  Concept  Document  (OCD). 

3.1  Product  Line  Architecture  Eramework 
(PLAF) 

The  OneSAF  Product  Line  Architecture  Framework 
(PLAF)  was  developed  over  a  period  from  mid  1999 
through  October  2000.  For  OneSAF  the  product  line 
concept  is  driven  by  the  need  to  support  multiple  user 
domains  with  a  variety  of  end  state  uses.  Thus  the 
variability  of  a  product  ranges  across  several 
dimensions: 

1)  The  type  of  supporting  infrastructure  (single 
processor  hosted  simulation  to  a  distributed  multi¬ 
processor,  multi-host  simulation), 

2)  The  type  of  human  interaction  ranging  from 
Human-in-the-loop  (HITL)  simulations  for  training 


and  mission  rehearsal  situations  to  closed  form 
analytic  uses  of  the  simulation. 

3)  The  use  of  specific  applications,  AAR,  simulated 
entity  composition,  etc.  for  each  user  domain. 

The  initial  software  development  process  used  in 
understanding  the  design  impacts  driven  by  the 
requirements  was  based  on  a  tailored  derivation  of  the 
Texel/Williams  Software  Development  Process 
described  in  detail  in  [10].  This  process  describes  a  use 
case  based  approach  intended  to  explain  the  objects  and 
interactions  starting  at  the  user  interaction  level  and 
ending  with  pure  software  representations.  This  process 
was  modified  and  used  only  in  the  conceptual 
exploration  phases,  prior  to  contract  award,  to  focus 
strictly  on  the  OneSAF  domain  user’s  perspectives 
instead  of  internal  software  design.  Together  the 
products  of  this  analysis  (the  End  State  Scenarios, 
Operational  Architectures,  OneSAF  Use  Cases, 
OneSAF  Lifecycle,  and  User  Categories)  makeup  the 
OneSAF  Operational  Concept  Document  (OCD).  This 
initial  analysis  also  laid  the  foundation  for  the  products 
and  components  described  within  the  OneSAF  PLAF. 

The  PLAF  is  to  be  used  to  guide  the  definition  of 
individual  components,  their  services,  and  interfaces  so 
that  they  can  be  independently  developed  and  then 
combined  to  support  a  variety  of  products  and  system 
configurations.  It  is  left  to  the  OneSAF  Architecture 
and  Integration  contractor  to  determine  and  provide 
appropriate  definition  to  the  extent  to  which  the 
components  and  products  can  be  combined 
dynamically,  during  run-time,  or  statically,  during 
compile  time. 

The  PLAF  supports  a  hierarchical  composition  process 
to  create  specific  system  configurations  to  support  the 
different  user  domains.  A  pictorial  representation,  taken 
from  [11],  is  shown  in  figure  2.2.  At  the  highest  level 
products  are  combined  to  create  the  system 
configurations.  The  products  are  complete  units  of 
functionality  such  as  an  After  Action  Review  product. 
Products  themselves  are  made  up  of  one  or  more 
components.  Components  are  the  elements  that  can  be 
developed  independently  and  therefore  must  have 
complete  service  and  interface  definitions  along  with  a 
formal  documented  process  for  combining  and  ensuring 
that  the  overall  performance  requirements  are  met. 


Product  Line  Structure  (DRAFT) 

System  Products 

Configurations  (Composed  of 

(Composed  of  Components) 

Products)  (Example:  Partial  List) 

Components 
(Tasked  Out  for 
Development) 

TEMO 

RDA 

ACR 

^^^Military  Scenario  Planner: 

Toolset  used  during  Exercise  Planning 

Phase  to  meet  TEMO,  RDA,  and  ACR 
Objectives 

Military  Scenario  Development 
Environment  (MSDE) 

System  and  Model  Composer: 
Toolset  used  during  Model  Composition 
Phase  to  create  new  simulated  entities  and^ 
environment  required  within  scenario 

Entity  Composer 

Behavior  Composer 

Environment  Composer 

Unit  Composer 

Simulation  Generator:  Toolset 
used  during  Scenario  Generation  Phase 
to  Create  a  simulation  meeting  scenario 
recjuiremenis 

Env  DB  Gen  Env 

Sira  Scenario  Dev  Env 

Data  Collection  Spec  Tool 

Figure  2.2,  OneSAF  Product  Line  Structure 


Figure  2.3,  again  taken  from  [11],  shows  the  initial 
breakout  of  system  configurations,  products,  and 
components  using  a  layering  approach.  The  top  block 
shows  the  end  user  configurations  supporting  the 
TEMO,  RDA,  and  ACR  domains.  Next  the  product 
layer  is  given  showing  the  products  necessary  to 
compose  a  complete  system  configuration.  Under  each 
product  is  a  list  of  the  components  that  need  to  be 
developed  or  harvested  through  reuse  to  support  the 
product.  There  may  be  a  number  of  “same  name” 
components  that  are  developed  in  order  to  support  the 
variability  of  the  OneSAF  requirements.  These 
components  will  need  to  be  easily  interchanged  in  order 
to  support  the  end  user  system  configurations. 


Figure  2.3,  the  OneSAF  Product  Line  Architecture 
Framework 


This  section  defines  the  current  set  of  Products  and  the 
components  that  can  be  composed  by  the  user  to  create 
OneSAF  system  configurations  that  are  suitable  for  any 
particular  use  case.  The  descriptions  provided  here  are 
consistent  with  those  contained  within  the  OneSAF 
TRD  but  are  presented  as  high  level  summaries.  The 


TRD  provides  the  detailed  requirements  for  each  of  the 
identified  PLAF  Products  and  Components  [12]. 


3.1.1  Military  Scenario  Planner  Product 

The  Military  Scenario  Planner  supports  the  definition  of 
a  Military  Scenario  Specification  in  extensible  Markup 
Language  (XML)  that  will  be  used  in  future  simulation 
events.  It  provides  a  GUI-based  mechanism  for 
selection  of  force  structure,  overlays,  and  control 
measures  that  bound  the  scenario.  It  may  also  use 
operational  graphics  generated  by  organic  C4I  systems. 
It  is  a  goal  of  this  product  to  be  able  to  produce  military 
scenarios  that  can  be  shared  by  multiple  simulations 
(e.g.,  WARSIM  and  COMBAT^^').  The  Military 
Scenario  Development  Environment  (MSDE) 
Component  is  the  single  component  within  the  Military 
Scenario  Planner. 


3.1.2  Model  &  System  Composer  Product 

The  Model  &  System  Composer  Product  supports  the 
creation  of  a  composite  entity,  behavior,  or 
environmental  element  from  a  collection  of  primitive 
components.  Metadata  associated  with  each  primitive 
constrains  the  process  in  the  creation  of  allowable 
constructs.  At  a  system  level,  the  composer  supports 
the  creation  of  tailored  applications  from  desired 
software  modules  or  artifacts.  The  components  within 
this  product  are  briefly  described  below: 

The  Entity  Composer  will  provide  the  capability  to 
construct  entities  like  tanks  from  supporting  constructs 
like  tracks,  turrets,  guns,  etc.  Information  describing  the 
new  entity  can  then  be  entered  within  the  entity 
composer  tool.  The  entity  composer  will  also  allow 
behaviors  and  physical  models  to  be  bound  to  specific 
entities. 

The  Unit  Composer  will  provide  the  capability  to 
construct  military  units  (organizations)  from  other  unit 
constructs.  Information  describing  the  new  unit  can 
then  be  entered  within  the  unit  composer  tool.  The  unit 
composer  will  also  allow  behaviors  to  be  bound  to 
specific  units. 

The  Behavior  Composer  will  provide  the  capability  to 
construct  complex  behaviors  from  other  primitive 
behavior  types.  Complex  behaviors,  along  with  their 
relevant  metadata,  will  be  specified  in  an  XML  based 
Behavior  Specification  Language.  Information 
describing  the  new  behavior  can  then  be  entered  within 
the  behavior  composer  tool. 


The  OneSAF  Environment  Composer  will  provide  the 
user  the  capability  to  compose  the  synthetic 
environment  to  include,  but  not  limited  to,  geographic 
location,  terrain  representation  and  resolution,  feature 
representation  and  resolution,  atmospheric  effects 
representation  and  resolution,  bathymetric 
representation  and  resolution,  etc. 

The  OneSAF  System  Composer  will  provide  the  user 
the  capability  to  compose  and  tailor  the  product  line 
products  and  components  to  create  a  specific  system 
configuration  (create  combat  simulation  from  high 
resolution  entities/units,  configure  executive  to  run  as 
fast  as  possible,  repeatable  mode,  etc.). 


3.1.3  Simulation  Generator  Product 

The  OneSAF  Simulation  Generator  Product  provides  a 
GUI-based  mechanism  for  the  selection  of  the 
appropriate  terrain  and  environmental  information, 
forces,  factional  relationships,  non-combatant 
organizations,  data  collection  information  and  other 
elements  necessary  to  capture  the  requirements  of  the 
scenario  at  execution.  The  selection  process  is  supported 
by  the  examination  of  metadata  describing  each 
element.  The  Generator  uses  the  XML  Military  Scenario 
Specification  created  by  the  MSDE  component  as  a 
basis  for  extension.  The  Simulation  Generator  supports 
association  of  synthetic  entities  with  map  based  control 
measures  and  temporal  order  execution  sequences.  The 
Simulation  Scenario  Specification  is  stored  in  an  XML- 
based  format  for  further  processing  by  the  Technical 
Manager  Product.  The  Components  within  this  Product 
are  briefly  described  below: 

The  OneSAF  Simulation  Scenario  Development 
Environment(SSDE)  provides  the  GUI-based 
mechanism  for  the  selection  of  the  appropriate  forces, 
factional  relationships,  non-combatant  organizations, 
and  other  elements  necessary  to  capture  the 
requirements  of  the  scenario  at  execution.  It  updates  the 
Simulation  Scenario  Specification  with  this  additional 
data. 

The  OneSAF  Environment  Database  Generation 
Environment(EDGE)  Component  provides  the  GUI- 
based  mechanism  for  the  selection  of  the  appropriate 
terrain  and  environmental  data  necessary  to  capture  the 
requirements  of  the  scenario  at  execution.  It  updates  the 
Simulation  Scenario  Specification  with  this  additional 
data. 

The  OneSAF  Data  Collection  Specification  Tool 

(DC  ST)  will  allow  the  user  to  identify  the  data  items  of 
interest  for  collection  during  simulation  execution.  It 


updates  the  Simulation  Scenario  Specification  with  this 
additional  data. 


3.1.4  Technical  Manager  Product 

The  OneSAF  Technical  Manager  Product  will  provide 
GUI-based  mechanisms  and  the  services  to  support 
exercise  configuration  and  setup.  The  components 
within  this  product  are  briefly  described  below: 

The  OneSAF  Simulation  Executable  Builder  parses 
the  XML  Simulation  Scenario  Specification  and 
provides  the  user  tools  to  partition  the  scenario  into  sub¬ 
elements  and  build  required  executables.  The 
Simulation  Executable  Builder  extends  the  scenario 
specification  by  embedding  a  partitioning  scheme  and 
executable  assignments. 

The  OneSAF  Simulation  Configuration  Tool(SCT) 

will  provide  a  GUI-based  mechanism  for  the 
configuration  of  hosts  and  networks  that  will  participate 
in  a  OneSAF  execution.  The  SCT  will  use  the  XML 
Simulation  Scenario  Specifications  to  guide  assignment 
of  software  to  appropriate  computational  hosts.  The 
SCT  downloads  required  executables  that  are  built  by 
the  Simulation  Executable  Builder  to  the  hosts  and 
hands  control  over  to  the  Simulation  Control  Product. 

The  OneSAF  Federation  Development  Tool  will 
provide  a  GUI-based  mechanism  for  supporting  the 
HLA  federation  development  process.  This  tool  shall 
support  OneSAF  Simulation  Object  Model  (SOM)  to 
Federation  Object  Model  (FOM)  mapping  in  support  of 
federation  execution. 

The  OneSAF  Performance  Modeling  Tool  will 
provide  a  GUI-based  mechanism  to  predict  runtime 
performance  of  a  particular  OneSAF  scenario  via  a 
simulation  of  OneSAF  execution. 

The  OneSAF  Blaster/Network  Loader  Tool  will 
provide  a  GUI-based  mechanism  to  assess  network 
performance  and  capacity  to  support  a  OneSAF 
execution.  The  Blaster/Network  Loader  Tool  will 
provide  applications  for  benchmarking  absolute 
performance  for  network  comparisons.  In  addition,  for 
a  given  network  layout  the  Blaster/Network  Loader  tool 
shall  provide  utilities  for  estimating  network  resource 
requirements  for  a  given  scenario. 


3.1.5  Simulation  Core  Product 

The  OneSAF  Simulation  Core  Product  will  provide  the 
foundational  OneSAF  simulation  services/executive  and 


core  modeling  capabilities  and  shall  provide  a  GUI  to 
monitor  and  control  these  services.  The  simulation 
services  include,  but  are  not  limited  to,  time  and  event 
management,  random  number  generation  and  stream 
services,  probability  distribution  library  services,  RTI 
interface  services,  standalone  single  computer 
simulation  implementation  services  and  distributed 
simulation  services,  environmental  models,  unit  models, 
entity  models,  etc.  The  modeling  capabilities  include 
modeling  of  Units,  Entities,  Behaviors,  Physical 
Models,  and  the  Environment.  The  components  within 
this  product  are  briefly  described  below: 

The  OneSAF  Simulation  Core  Services  shall  include, 
but  are  not  limited  to,  time  and  event  management, 
random  number  generation  and  stream  services, 
probability  distribution  library  services,  RTI  interface 
services,  standalone  single  computer  simulation 
implementation  services  and  distributed  simulation 
services,  etc. 

The  OneSAF  Environment  Models  comprise  those 
environmental  models,  both  dynamic  and  static,  that  are 
built  in  support  of  the  OneSAF  requirements  set. 

The  OneSAE  Unit  Models  comprise  the  military 
organizational  or  unit  models  developed  in  support  of 
the  OneSAF  requirements  set.  The  unit  is  defined  as  a 
component  of  a  military,  paramilitary,  quasi-military 
(guerilla  or  terrorist  cell,  etc.),  governmental  or  other 
organizational  hierarchy.  Traditional  military  units  are 
organized  by  echelon  (e.g.,  brigade,  battalion,  company, 
platoon,  squad,  team/crew,  and  individual)  with  well- 
established  command  and  control  structures. 
Paramilitary  and  quasi-military  units  may  cooperate 
through  more  dynamic  or  ad-hoc  relationship  structures. 
The  OneSAF  Unit  Models  provide  the  runtime 
representation  of  the  Units  identified  within  the 
Simulation  Scenario  Specification. 

The  OneSAF  Entity  Models  are  comprised  of 
Command  Entities  or  Basic  Entities.  A  Command 
Entity  is  the  physical  representation  of  the  command 
node  (squad/platoon/company  command  posts  and 
battalion  Tactical  Attack  Center  (TAC)  and  Tactical 
Operations  Center  (TOC),  civilian  leader,  etc)  within 
the  simulation  and  the  associated  command  decision 
making  capability.  A  Basic  Entity  is  a  system  that  can 
be  modeled  and/or  represented  within  the  synthetic 
environment  and  that  can  express  observable  behavior. 
An  entity  may  be  a  life  form  (e.g.,  human,  military 
working  dog)  or  a  platform  (e.g.,  tank,  helicopter).  The 
OneSAF  Entity  Models  provide  the  runtime 
representation  of  the  Entities  identified  within  the 
Simulation  Scenario  Specification. 


The  OneSAF  Behavior  Models  provide  the  runtime 
modeling  of  the  cognitive  aspect  of  Units  and  Entities 
and  utilize  the  XML  based  behaviors  that  have  been 
composed  for  each  of  the  scenario’s  Units  and  Entities. 

The  OneSAF  Physieal  models  provide  the 
mathematical  representation  of  combat  systems  and 
their  interactions  with  the  environment  and  other 
entities.  Physical  models  may  be  represented  at 
multiple  levels  of  fidelity  as  defined  by  the  TRD. 


3.1.6  Simulation  Controller  Product 

The  Simulation  Controller  Product  provides  all 
controlling  mechanisms,  displays,  and  devices  for 
interacting  with  OneSAF  during  runtime.  These 
displays  shall  include  map-based  (PVD)  representation 
of  terrain  database  including  unit  and  platform 
locations,  overlays,  and  supporting  contextual 
information  for  simulation  execution.  Simulation 
Control  will  provide  controls  for  interacting  with  and 
directing  behavior  of  battlefield  entities  represented  in 
OneSAF.  In  addition,  the  Simulation  Control  Product 
monitors  the  simulation  performance  during  execution 
and  can  dynamically  shutdown  and  restart  executables 
as  necessary.  The  components  within  this  product  are 
briefly  described  below: 

The  OneSAF  Management  and  Control  Services  are 
those  necessary  to  view  and  control  the  simulated 
entities  as  a  technical  controller,  battlemaster/senior 
controller,  puckster,  analyst,  or  (Low  Overhead  Driver) 
LOD  user. 

The  OneSAF  Federation  Management  Tool  shall 
provide  mechanisms  to  monitor  and  control  OneSAF 
Federations. 

The  OneSAF  Data  Collector  provides  the  services  to 
collect  and  store  all  of  the  data  identified  within  the 
XML  based  Data  Collection  Specification  created  by 
the  Data  Collection  Specification  Tool. 

The  OneSAF  Annotator  will  provide  an 
observer/controller  or  other  remote  user  the  ability  to 
record  electronic  form  based  data  entry  regarding  the 
simulation  event  to  support  AAR  and  Analysis 
activities.  It  is  envisioned  that  this  will  be  implemented 
in  a  Personal  Digital  Assistant  (PDA)-based  application. 


3.1.7  OneSAF  C4I  Adapter  Product 

The  OneSAF  C4I  Adapter  provides  bi-directional 
translation,  connection,  and  control  and  monitoring  of 
information  flowing  between  real-world  C4I  systems 
and  OneSAF.  The  components  within  this  product  are 
briefly  described  below: 

The  OneSAF  Monitor  and  Control  GUI  Services  will 
provide  mechanisms  to  monitor  and  control  the  C4I 
adapter  settings  as  well  as  manage,  control,  or  modify 
the  data  flowing  between  the  C4I  system  and  OneSAF. 

The  OneSAF  Translation  Services  will  provide  two 
way  translation  services  that  translate  internal  OneSAF 
formats  to  C4I  formats  and  vice  versa.  These 
translations  may  include  and  are  not  limited  to  voice, 
binary,  human  readable,  and  database  formats. 

The  OneSAF  Connection  Services  will  provide  a 
mechanism  to  connect  the  Adapter  to  specific  C4I 
systems  using  inherent  C4I  protocols  and  physical 
connection  mechanisms.  These  may  include  but  are  not 
limited  to  serial  communication  lines,  Ethernet,  wireless 
communications,  etc. 


3.1.8  After  Action  Review  (AAR)  Product 

The  OneSAF  After  Action  Review  Product  will  support 
graphical  review,  analysis  and  presentation  of  all  data 
collected  during  the  OneSAF  execution.  The  toolset 
shall  support  mining  of  collected  data  to  construct 
Measures  of  Effectiveness  (MOEs)/Measures  of 
Performance  (MOPs)  and  analytical  charts  and  graphs 
as  well  as  allowing  data  export  to  Commercial  Off  The 
Shelf  Software  (COTS)  Office  Automation  and 
analytical  review  tools.  The  Analysis  and  Review 
component  is  the  sole  component  within  this  product. 


3.1.9  Maintenance  Environment  Product 

The  OneSAF  Maintenance  Environment  Product 
provides  an  integrated  environment  to  manage  all  data 
and  artifacts  associated  with  the  OneSAF  Product  Line. 
These  tools  shall  span  the  software  development 
lifecycle,  from  requirements  engineering  to  software 
maintenance.  The  Components  within  this  Product  are 
briefly  described  below: 


The  OneSAF  Configuration  Management  Utilities 

will  support  the  configuration  management  and 
maintenance  of  all  data  within  the  repository. 


The  OneSAF  System  Accounting  Utilities  will  support 
management  of  user  accounts  and  privileges. 

The  OneSAF  System  Asset  Management  Utilities  will 
support  the  setup  and  management  of  network  assets 
that  include,  but  are  not  limited  to,  communications 
links,  processing  nodes,  peripheral  devices,  etc. 

The  OneSAF  System  Distribution  Services  will 
support  the  distribution  of  the  OneSAF  system  and 
product  lines  to  the  user  sites. 

The  OneSAF  Information  Security  Utilities  will  assist 
the  user  in  management  of  classified  information  in  the 
Repository. 

The  OneSAF  Data  Harvesting  and  Translation 

utilities  will  support  the  harvesting  and  automated 
translation  of  data  sources  commonly  used  in  legacy 
systems  into  common  data  standards  and  formats  to  be 
used  within  the  OneSAF  Product  Line  Architecture 
Specification. 

The  OneSAF  Software  Engineering  Environment 

will  provide  tools  to  support  product  line  and  software 
analysis,  software  requirements  traceability,  software 
design,  software  coding,  software  debugging,  software 
testing,  and  software  configuration  management  and 
revision  control. 

The  OneSAF  Software  Installation  Tool  will  provide 
a  "wizard  like"  install  tool  to  automate  the  software 
installation  process.  This  component  will  verify 
minimum  system  hardware  and  software  requirements 
are  met.  These  requirements  will  include  things  like 
CPU  Version,  available  disk  space,  Operating  System 
Version,  existence  of  necessary  supporting  software, 
etc. 

The  OneSAF  Online  Help  and  Tutorials  utilities  will 
support  the  definition  and  use  of  context  sensitive  help 
and  on-line  tutorial  capabilities. 

The  OneSAF  Verification  and  Validation  Tool  will 
provide  user  access  to  data  confirming  that  the  software 
development  process  is  being  followed.  This  data 
includes  but  is  not  limited  to  requirements  traceability, 
coding  standard  adherence  proof,  internal  software 
documentation  standard  adherence  proof,  Application 
Programmer’s  Interface  (API)  standard  adherence  proof, 
etc.  The  OneSAF  Verification  and  Validation  Tool  will 
also  provide  data  aiding  in  the  validation  of  the  models 
against  real-world  data.  This  data  may  be  provided 
through  software  instrumentation  techniques  or  other 
data  creation  and  access  methods. 


The  OneSAF  Data  Management  Tool  will  provide 
mechanisms  to  access,  review,  modify,  archive,  and 
analyze  data  within  the  OneSAF  Repository. 

The  OneSAF  Repository  will  accommodate  all 
OneSAF  data  and  information.  The  repository  must 
accommodate,  at  a  minimum,  the  following  types  of 
data:  system  and  software  documentation,  system  and 
software  source  code  and  executable  code,  system  and 
software  product  configuration  data  and  change  history, 
any  metadata  necessary  to  support  simulation 
composition  activities,  scenario  data,  simulation 
execution  data,  simulation  execution  performance 
metrics,  results  of  analysis  performed  on  simulation 
data,  after  action  review  data,  etc. 


3.2  Technical  Requirements  Document  (TRD) 

The  TRD  is  the  companion  document  to  the  PLAF.  It 
provides  the  technical  requirements  for  the  PLAF 
products  and  components  and  is  traceable  back  to  the 
ORD  [12].  The  TRD  evolved  throughout  the  duration 
of  the  A-IPTs  existence.  The  first  step  in  the  TRD’s 
development  was  to  transform  the  structure  of  ORD 
based  requirements  into  independent  “shall” 
requirements.  This  included  deriving  requirements, 
based  on  information  gained  during  concept 
exploration,  to  add  a  level  of  richness  to  the  ORD 
requirements.  Again  the  user  domains  were  involved 
throughout  this  process.  Next,  the  TRD  paragraphs  or 
modules  as  they  are  called  in  DOORS  were  categorized 
or  grouped  into  the  products  within  the  Product  Line 
Architecture  Framework  (PLAF). 

3.3  Operational  Concept  Document  (OCD) 

Work  on  the  OCD  also  began  in  December  of  1999  and 
ran  through  December  of  2000  [13].  The  OCD  is  not  a 
single  document;  instead  it  is  a  collection  of  several 
analysis  artifacts: 

•  End  State  Scenarios:  seven  from  the  ACR  domain, 
two  from  the  RDA  domain,  and  six  from  the 
TEMO  domain, 

•  Four  representative  Operational  Architectures, 

•  A  set  of  OneSAF  use  cases  -  a  representative  set 
from  each  domain, 

•  A  OneSAF  exercise  lifecycle  overview,  and 

•  The  set  of  OneSAF  user  categories. 

The  types  of  information  contained  in  each  one  of  the 
products  reflects  the  culmination  of  various  meetings 
and  workshops  held  by  the  A-IPT. 


The  End  State  Scenarios  represent  the  types  of  military 
operations  that  have  to  be  represented  in  OneSAF  to 
meet  the  domains'  OneSAF  requirements.  They  include 
the  military  plans,  orders,  units  involved,  and  the 
various  behaviors  of  the  units. 

The  four  representative  operation  architectures:  1)  CO  A 
Doctrine  and  Combat  Development  Tool,  2)  Leader  and 
Staff  Training  -  Seminar  Driver,  3)  Material 
Development  Tool,  and  4)  Seamless  Training  Exercise 
Driver  contain  the  simulation  configuration 
requirements  for  each  of  the  representative  uses  of 
OneSAF.  The  four  operational  architectures  attempt  to 
show  the  variations  in  computer,  network,  and 
personnel  that  must  be  supported  by  the  OneSAF 
system. 

The  Operational  Use  Cases  show  how  OneSAF  will  be 
used  within  each  domain.  The  complete  set  of  use  cases 
set  the  boundaries  for  the  OneSAF  system.  The  use 
cases  from  each  domain  are  roughly  based  on  the 
OneSAF  Lifecycle. 

The  OneSAF  Lifecycle  was  created  by  looking  at 
processes  used  by  legacy  systems,  interviewing  Subject 
Matter  Experts,  and  reviewing  the  ORD  and  the  FILA 
Federation  Development  Process  (FEDEP).  The 
OneSAF  Lifecycle,  as  summarized  from  [13],  is 
described  by  the  following  10  phases: 

1  .  Event  Planning:  Operational  objectives  are 

identified  and  broken  down  into  specific  functional 
requirements.  This  phase  normally  lasts  several 
months  in  duration  and  requires  a  significant 
amount  of  collaboration  between  event  planners. 

2  .  Database  Development:  The  necessary 

environmental,  unit,  behavior,  and  equipment 
databases  are  determined.  Datasets  are  investigated 
to  identify  those  that  can  be  reused,  those  that  can 
be  created  through  modification,  and  those  that 
need  to  be  created  from  scratch. 

3 .  Software  Development:  Software  is  developed 
based  on  the  results  of  the  Database  Development 
Phase  investigation. 

4.  Model  Composition:  Models  are  generated  using 
the  model  composition  tools  within  OneSAF. 

5  .  Scenario  Generation:  All  software  based 

representations  required  to  execute  the  event  are 
selected  and  parameterized. 

6  .  Simulation  Configuration:  The  software  is 

allocated  to  computational  hosts  and  the  simulation 
network  is  designed  based  upon  event  performance 
requirements. 


7.  Systems  Test  and  Verification:  The  simulation  is 
run  in  a  trial  mode  to  see  if  it  executes  as  planned 
and  meets  performance  requirements. 

8 .  Simulation  Execution:  The  simulation  event  is 
executed. 

9 .  Post-Execution  Analysis/After  Action  Review: 

Data  collected  during  exercise  execution  is 
analyzed  and  fed  to  the  participants  in  analytical 
form  or  in  a  hotwash  training  forum.  This  can 
occur  during  and  after  exercise  execution. 

10.  Archival:  All  collected  data  is  archived  for  easy 
retrieval  and  analysis. 

The  final  piece  of  the  OCD  is  the  User  Category  List. 
This  list  is  intended  to  identify  the  critical  roles  played 
by  users  of  OneSAF.  This  information  will  be  used  to 
create  appropriate  GUIs  allowing  access  to  the  functions 
necessary  for  each  user  type.  The  list  of  User 
Categories,  extracted  from  [13],  is  provided  below: 

1 .  Software  Developer  -  Responsible  for  the  creation 
of  a  specific  software  artifact. 

2.  Model  Composer  -  Responsible  for  the  creation  of 
a  composite  entity/behavior/unit  from  a  set  of 
existing  primitives  or  other  composites.  This 
process  includes  changing  parametric  data  and  the 
selection  of  appropriate  fidelity  within  the  physical 
models. 

3  .  Database  Developer  -  Responsible  for  the 
development  of  databases  in  support  of  a  simulation 
event 

4.  Scenario  Developer  -  Responsible  for  operational 
planning  and  development  of  the  forces  and 
environment  for  the  execution  of  a  simulation 
event. 

5  .  Configuration  Manager  -  Responsible  for 
performing  version  control  and  management  of  all 
aspects  of  the  baseline  product. 

6.  Data  Manager  -  Responsible  for  organization  and 
classification  of  data  supporting  an  execution  of  the 
simulation. 

7 .  System  Administrator  -  Super-User,  responsible 
for  the  successful  operation  of  the  OneSAF  system. 

8.  Technical  Controller  -  Responsible  for  the  set  up, 
configuration,  monitoring,  use,  and  maintenance  of 
the  assets  supporting  the  simulation  execution. 

9.  Observer/Controller  -  Responsible  for  evaluation 
of  the  training  audience  and  recording  of 
appropriate  events/observations. 

10.  Puckster/Training  Audience  -  Responsible  for 
controlling  SAF  entities  during  execution  of  a 
scenario. 


11.  Analyst  -  Responsible  for  planning,  preparation, 
conduct,  and  analysis  of  the  simulation  event. 

12.  LOD  User  -  Non-technical  user  with  limited  set  of 
tools  to  tailor  and  run  a  predefined  scenario. 

13.  Model  Validator  -  Domain  Subject  Matter  Expert 
(SME)  responsible  for  validation  of  the  models. 

3.4  Reuse  Direction  and  Guidance  (RDG) 

During  the  spring  of  2000,  the  A-IPT  performed  a  reuse 
assessment  to  identify  opportunities  to  leverage 
developmental  artifacts  from  existing  programs.  The 
reuse  assessment  resulted  in  the  RDG  document  and  a 
supporting  reuse  repository  [14].  The  RDG  is  directly 
traceable  into  the  appropriate  products  within  the  reuse 
repository  that  reference  complete  fielded  and 
developmental  products  from  numerous  programs 
including  WARSIM,  CCTT,  COMBAT^^',  and  the 
0TB.  As  new  reuse  opportunities  are  identified  and  as 
existing  baselines  mature  documentation  and  other 
supporting  artifacts  will  be  collected  and  added  to  the 
repository.  The  intent  of  the  reuse  repository  is  to 
provide  the  OneSAF  contractors  with  the  government’s 
authoritative  expectations  for  product  reuse.  The  reuse 
definitions  went  through  a  number  of  iterations  and 
initially  considered  knowledge  acquisition/ 
requirements,  design,  and  code  reuse.  With  the  specific 
type  of  reuse  being  categorized  by  the  product  being 
reused.  Another  level  was  associated  with  the 
completeness  in  which  a  reused  product  satisfied  an 
existing  OneSAF  requirement.  From  complete 
satisfaction  at  the  product  level,  to  partial  satisfaction,  to 
simple  algorithmic  reuse.  The  following  final 
definitions  are  provided  within  the  OneSAF  RDG 
document  [14]: 

“Directed  Reuse:  The  contractor  is  directed  to  reuse  the 
identified  product  as  a  starting  point  for  OneSAF 
development.  Substantial  life  cycle  cost  benefits  must 
be  demonstrated  in  order  to  propose  a  different  starting 
point.  ” 

“Recommended  Reuse:  The  contractor  is  directed  to 
consider  the  reuse  of  the  identified  products  as  a 
starting  point  for  OneSAF  development.  Life  cycle 
benefits  of  using  products  should  be  shown  along  with 
proposed  starting  point.  ” 

The  directed  reuse  analysis  began  with  the  team  looking 
at  products  nominated  within  each  domain  and  the  reuse 
criteria  defined  by  the  A-IPT.  The  members  then  were 
assigned  specific  products  to  assess.  The  assessment 
centered  on  meeting  the  functional  requirements  as 
stated  within  the  ORD  and  TRD.  The  four-step 
assessment  process  is  as  follows: 


1  .  Identify  a  specific  functional  area  like  C4I 
interfaces, 

2.  Produce  a  basic  statement  of  the  requirements, 

3  .  Analyze  specific  products  based  on  the 

requirements,  and 

4.  Tag  the  product  as  directed,  recommended,  or  not 
to  be  reused,  and  provide  commentary  as  needed. 

In  all,  there  are  approximately  30  items  categorized  as 

government  directed  reuse  and  6  as  recommended  reuse. 

The  basic  layout  for  each  reuse  assessment  is  shown 

below. 

•  Functional  Area:  Direct  reference  to  TRD. 

•  Basic  Statement  of  Requirements:  Requirements 
extracted  from  TRD. 

•  Products  Considered:  Listing  of  the  products  that 
were  considered  by  the  A-IPT  members  for  reuse 

•  Directed  Reuse:  Specific  products  the  government 
has  selected  for  directed  reuse 

•  Recommended  Reuse:  Specific  products  the 
government  has  selected  for  recommended  reuse. 

•  Additional  Commentary:  Additional  comments 
giving  rationale  or  additional  detail  behind  the 
direction  or  recommendation. 

4  International  Community 
Collaboration  Activities 


4.1  Organizational  Relationships 

Since  1997,  the  OneSAF  program  has  sought  out  and 
actively  participated  with  international  organizations  in 
the  refinement  of  OneSAF  requirements  and  concepts. 
OneSAF  has  worked  specifically  with  UK  Defence 
Evaluation  and  Research  Agency  (DERA)  under  an 
established  UK-US  Information  Exchange  Agreement 
[15]  to  perform  collaborative  research  and  development 
into  next  generation  simulation  concepts.  The  OneSAF 
program  is  currently  supporting  the  establishment  of  a 
modeling  and  simulation  working  group  as  part  of  the 
Australian,  British,  Canadian,  and  American  (ABCA) 
Standardization  Program  [17]  with  the  goal  of 
expanding  our  opportunities  for  collaboration  to  include 
the  appropriate  Canadian  and  Australian  defense 
organizations.  Initial  steps  have  been  taken  with  these 
organizations  to  identify  common  objectives  and 
opportunities  for  collaboration  but  the  specifics  of  these 
arrangements  are  still  in  the  early  discussion  phases. 


4.2  Early  Technical  Transition 

The  OneSAF  program  has  inserted  concepts  into  the 
Product  Line  approach  that  not  only  support  the 
interoperability  and  early  use  of  the  program  by  the  U.S. 
Army  community,  but  support  the  early  use  of  OneSAF 
by  the  international  community  as  well.  These  concepts 
support  the  transition  of  the  international  community 
from  their  current  ModSAF  applications  to  the 
appropriate  internationally  releasable  OneSAF  version 
by  providing  data/scenario  harvesting  tools  that  convert 
ModSAF  related  data  and  scenarios  into  the  OneSAF 
XML  based  Scenario  Specification  Language.  In 
addition,  OneSAF  will  also  provide  an  early  capability 
to  define  unique  service/country  scenarios  (unit 
structures,  entities,  etc.)  and  unique  service/country  unit 
and  entity  behaviors  (both  BLUFOR  and  OPFOR)  by 
providing  early  access  to  the  toolset  supporting  the 
OneSAF  XML  based  Scenario  Specification  Language 
and  Behavioral  Specification  Language. 

5  Summary 

In  summary,  the  OneSAF  program  will  provide  the  U.S. 
Anny  with  substantial  lifecycle  savings  by  significantly 
reducing  redundant  SAF  software  development  and 
evolution  efforts,  increasing  interoperability  and  reusing 
products  across  the  SAF  user  community,  and  by  using 
leading  edge  product  line  architecture  and  design 
techniques  to  provide  a  modular,  composable  system 
that  will  support  Army  requirements  into  the  future.  To 
support  this  the  Army  leadership  including  STRICOM, 
the  TPO,  and  the  Army  user  domains:  ACR,  RDA, 
TEMO  have  collaborated  to  provide  a  series  of  products 
which  convey  the  Government’s  OneSAF  requirements 
and  product  line  concepts  to  our  industry  partners  and 
other  external  organizations. 
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